Field of the Invention
The present invention relates to a mechanism used for discovering an application function or server used in a communication connection. In particular, the present invention is related to an improved mechanism ensuring that a network control element, such as a gateway network element, and a terminal equipment, such as a user equipment, shall contact the same server/proxy, such as a Proxy-Call State Control Function (P-CSCF) of an IP Multimedia Subsystem (IMS) network when establishing a communication connection.
For the purpose of the present invention to be described herein below, it should be noted that                a terminal equipment or user equipment (UE) may for example be any device by means of which a user may access a communication network; this implies mobile as well as non-mobile devices and networks, independent of the technology platform on which they are based; only as an example, it is noted that communication equipments operated according to principles standardized by the 3rd Generation Partnership Project 3GPP and known for example as UMTS terminals are suitable for being used in connection with the present invention; however, the terminal equipments or user equipments may also be of a type using functions and components specified by the Internet Engineering Task Force (IETF).        when reference is made herein to a call or session, this exemplifies only a general example of a connection of any content; content as used in the present invention is intended to mean multimedia data of at least one of audio data (e.g. speech), video data, image data, text data, and meta data descriptive of attributes of the audio, video, image and/or text data, any combination thereof or even, alternatively or additionally, other data such as, as a further example, program code of an application program to be accessed/downloaded;        method steps likely to be implemented as software code portions and being run using a processor at one of the entities described herein below are software code independent and can be specified using any known or future developed programming language;        method steps and/or devices likely to be implemented as hardware components at one of the entities are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS, CMOS, BiCMOS, ECL, TTL, etc, using for example ASIC components or DSP components, as an example;        generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the present invention;        devices or means or clients/servers can be implemented as individual devices or means, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device is preserved.        
Related Prior Art
In the last years, an increasing extension of communication networks, e.g. of wire based communication networks, such as the Integrated Services Digital Network (ISDN), or wireless communication networks, such as the cdma2000 (code division multiple access) system, cellular 3rd generation (3G) communication networks like the Universal Mobile Telecommunications System (UMTS), cellular 2nd generation (2G) communication networks like the Global System for Mobile communications (GSM), the General Packet Radio System (GPRS), the Enhanced Data Rates for Global Evolutions (EDGE), or other wireless communication system, such as the Wireless Local Area Network (WLAN), took place all over the world. Various organizations, such as the 3rd Generation Partnership Project (3GPP), Telecoms & Internet converged Services & Protocols for Advanced Networks (TISPAN), the International Telecommunication Union (ITU), 3rd Generation Partnership Project 2 (3GPP2), Internet Engineering Task Force (IETF), CableLabs and the like are working on standards for telecommunication network and multiple access environments.
A current technology to merge the Internet with the cellular telecommunication world is the Internet Protocol (IP) Multimedia Subsystem or IMS. IMS is a standardized architecture for operators intending to provide mobile and fixed multimedia services. IMS uses a Voice over IP (VoIP) implementation based on a 3GPP standardized implementation of Session Initiation Protocol (SIP) and runs over the standard Internet Protocol (IP). Both packet-switched (PS) and circuit switched (CS) communication systems are supported.
When a communication connection or session is to be started, the communication path has to be established and various configuration processes are to be executed in order to set up the necessary network elements, but also to set up policy and charging rules for the connection.
One example for the steps effected during the communication connection establishment is shown in FIG. 6.
In FIG. 6 a simplified signalling diagram is depicted illustrating the signalling during a communication connection establishment between a terminal equipment (UE) and a network. The network comprises a control network element, such as a GPRS Gateway Service Node (GGSN) as a core network element and a server node, such as a P-CSCF of an IMS, as well as a policy control element, such as a Policy and Charging Rules Function (PCRF), a Policy Decision Function (PDF), or Resource and Admission Control Sub-system (RACS). In the example diagram of FIG. 6, the PCRF and P-CSCF are depicted to be part of the same network element (collocated). However, it is to be noted that these elements may also be separate elements. As a protocol for controlling interface it is possible to use Diameter (in a 3GPP rel. 7 use case, for example), but also other protocols can be used as known by those skilled in the art.
In step 1, the UE activates the primary PDP (Packet Data Protocol) context by sending a corresponding request to the network, i.e. to the GGSN. In step 2, the GGSN selects a Policy control element (for example, an external or collocated PCRF) to contact based on the user's identity provided, for example, by the Mobile Subscriber ISDN (MSISDN) number. Then, in step 3, the GGSN sends a CCR (Credit Control Request) initial message to the selected Policy control element. This message includes the Context-Type AVP (Attribute Value Pair) set to PRIMARY and the IP address allocated to the UE. Although no IMS sessions exist, the Policy control element authorizes, in step 4, the primary PDP context activation by sending a CCA (Credit Control Answer) initial message with Result-Code AVP set to SUCCESS. The Policy control element may set maximum QoS limit for the primary (general purpose) PDP context according to operator policy (e.g. max traffic class of interactive or background) and may send preconfigured charging rules if a preconfigured rule set for general purpose PDP context is provided in the Policy control element. In step 5, the GGSN activates the primary PDP context. A list of P-CSCFs may be returned to the UE. If the Policy control element and P-CSCF are collocated, the same discovered addresses are sent to the UE. In steps 8 and 9, the UE successfully registers to the IMS via the P-CSCF. The GGSN will send future requests to the selected Policy control element, such as the PCRF.
Basically, there are three standard P-CSCF Discovery (or selection) mechanisms known:                The P-CSCF address can be received as a result of a GPRS/PDP context based P-CSCF discovery procedure by the network control element (such as the GGSN). In this connection, it is to be noted that a Policy and Charging Enforcement Function (PCEF), which is located in the GGSN, may be served by one or more PCRF nodes. The PCEF may contact the appropriate PCRF based on the packet data network (PDN) connected to, together with a UE identity information (if available, and which may be IP-CAN (IP Connectivity Access Network) specific). It is possible that the same PCRF is contacted for a specific UE irrespective of the IP-CAN used.        The very first terminals contacts only to a pre-configured P-CSCF address received by OTA (Over The Air). This means the address or the logic name of the P-CSCF has to be configured into the UE.        The P-CSCF address can be received as a result of DHCP (Dynamic Host Configuration Protocol) inquiry (i.e. a so-called DHCP based P-CSCF discovery mechanism).        
Furthermore, some proprietary solutions for server discovery are known.
However, as indicated above, there are several possible mechanisms proposed for a server (P-CSCF) selection of which only the PDP context based P-CSCF selection is working in specific network architectures. Thus, there could be a case where the UE has selected (for example due to a DHCP query) a different P-CSCF than the GGSN is contacting, or the GGSN is contacting to a Policy control element (for example PCRF) which is not connected to the P-CSCF the UE has contacted.
A corresponding example is shown in FIG. 7. FIG. 7 shows a simplified signalling diagram illustrating the signalling during a communication connection establishment between a terminal equipment (UE) and a network of a communication connection establishment, and is similar to that of FIG. 6 (it is to be noted that same steps of FIGS. 6 and 7 are denoted with same reference signs so that a corresponding description thereof is omitted).
Steps 1 to 5 of FIG. 7 are equivalent to steps 1 to 5 of FIG. 6. This means that the GGSN has activated the PDP context after communicating with the P-CSCF selected by it (i.e. PCRF/P-CSCF1; step 2). However, in case the P-CSCF discovery mechanism used by the UE is, for example, the DHCP based P-CSCF discovery mechanism, the GGSN could not know which P-CSCF is selected by the UE. This may result in a situation where the UE selects another P-CSCF (i.e. PCRF/P-CSCF2) than that selected by the GGSN, and sends a corresponding registration message (step 8) to this (second) P-CSCF2. The P-CSCF2 responds with a 200 OK SIP message to the register message (step 9) so that SIP registration is successful. However, when the UE sends an INVITE message, such as a SDP (Session Description Protocol) OFFER to the P-CSCF2 (step 10), the PCRF/P-CSCF2 will try to determine from the network uplink(UL)/downlink (DL) connections, to authorize the Quality of Service (QoS) and to determine the traffic category for media flows for the connection (step 11). Since the PCRF/P-CSCF2 is not the server initially selected and contacted by the GGSN for the UE, there will be a mismatch. Hence, the SIP session can not be successfully established which is notified to the UE in step 13 by a corresponding SDP answer.
In current network architectures, such as 3GPP networks, it is mandatory that a UE can freely decide which of the described mechanisms it will use to acquire the P-CSCF address. So, the P-CSCF discovery mechanism selection is up to terminals logic. However, this may cause a conflict since in some of current architectures the only mechanism usable for a P-CSCF discovery is the PDP context based P-CSCF discovery mechanism.
In addition, there are presently such terminals in use which supports only the OTA or only the DHCP based P-CSCF discovery, but lacks of supporting the GPRS based or PDP context based P-CSCF discovery mechanism.
Thus, there is the problem that by using the present discovery mechanisms in such a manner that the GGSN uses the GPRS/PDP context based one P-CSCF discovery mechanism and does not know the P-CSCF selected by the UE using, for example, the DHCP based P-CSCF discovery (or alternatively the address or logic name of P-CSCF has been configured into the UE), there may be selected different P-CSCFs so that a SIP session can not be established.